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Abstract 

In this note we revisit the so-called reactive programming style, 
which evolves from the synchronous programming model of the Es- 
terel language by weakening the assumption that the absence of an 
event can be detected instantaneously. We review some research di¬ 
rections that have been explored since the emergence of the reactive 
model ten years ago. We shall also outline some questions that remain 
to be investigated. 


1 Introduction 

In synchronous models the computation of a set of participants is regulated by 
a notion of instant. The Synchronous Language introduced in j!2j belongs to 
this category. A program in this language generally contains sub-programs 
running in parallel and interacting via shared signals. By default, at the 
beginning of each instant a signal is absent and once it is emitted it remains 
in that state till the end of the instant. The model can be regarded as a 
relaxation of the Esterel model [2] where the reaction to the absence of a 
signal is delayed to the following instant, thus avoiding the difficult problems 
due to causality cycles in Esterel programs. 
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The model has gradually evolved into a programming language for con¬ 
current applications and has been implemented in the context of various 
programming languages such as C, Java, Scheme, and Caml (see Sec¬ 
tion 01 below). The design accommodates a dynamic computing environment 
with threads entering or leaving the synchronisation space. In this context, 
it seems natural to suppose that the scheduling of the threads is only de¬ 
termined at run time (as opposed to certain synchronous languages such as 
Esterel or Lustre). 

The model is based on a cooperative notion of concurrency. This means 
that by default a running thread cannot be preempted unless it explicitly 
decides to return the control to the scheduler. This contrasts with the model 
of preemptive threads, where by default a running thread can be preempted 
at any point unless it explicitly requires that a series of actions is atomic. 
We refer to, e.g., [23J for an extended comparison of the cooperative and 
preemptive models. It appears that many typical “concurrent” applications 
such as event-driven controllers, data flow architectures, graphical user in¬ 
terfaces, simulations, web services, multiplayer games, are more effectively 
programmed in a cooperative (and possibly synchronous) model than in the 
preemptive one. 

The purpose of this note is to revisit the basic model and to review 
some research directions that have been explored since the emergence of the 
model ten years ago. We shall also outline some questions that remain to be 
investigated. 


2 The basic model 

In this section, we introduce our basic model which is largely inspired by 
the original proposal [12], and, as regards concurrency, by the FairThreads 
model [TO] . 

We assume a countable set of signal names s, s', ... and we let Int be 
a finite set of signal names representing an observable interface. A signal 
environment E is a partial function from signal names to boolean values 
true and false whose domain of definition dom(E) is finite and contains Int. 
Such an environment records the signals that have been emitted during the 
current instant, as well as the ones that exist but are still absent. The 
semantics should preserve the invariant that all signals defined in a program 
(see below) belong to the domain of definition of the related environment. 
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In particular, all signal names which are not in the domain of definition of 
the environment are guaranteed to be fresh, i.e., not used elsewhere in the 
program. 

We define a thread as an expression written according to the following 
grammar: 


T ::= 0 | (emit s) | (local s T ) | (thread T) 

| (when s T ) | (watch s T ) || A(s) | (T;T) 

where A(s), B( s),... denote thread identifiers with parameters s. As usual, 
each thread identifier is defined by exactly one equation A(s) = T. A thread 
is executed in the context of a signal environment which is shared with other 
concurrent threads. 

The intended semantics is as follows: 0 is the terminated thread; (emit s) 
emits s, i.e. sets it to true and terminates, (local s T) creates a fresh signal 
which is local to the thread T and executes T (this construct is a binder 
for the name s in T); (thread T) spawns a thread T which will be executed 
in parallel and terminates; (when s T) allows the execution of T whenever 
the signal s is present and suspends its execution otherwise; (watch s T) 
allows the execution of T but kills whatever is left of T at the end of the first 
instant where the signal s is present, T; T is the usual sequentialisation. This 
operational intuition is formalised in the following rules, where the predicate 
(T, E) (T 7 , E') means that the thread T in the environment E executes 
an atomic sequence of instructions (possibly none) resulting in the thread T 7 , 
the environment E ', and the spawning of the multi-set of threads P. 

(Tl) (().£) r (().£) 


(emit s,E ) (0, E[s := true]) 

irri \ (W/s]T,EU{s r ^ false}) V(T',E') s'? dom(E) 
1 3j (local s T,E) (T',E') 


^ (thread T,E) ^ T ll ((),£) 

^ i[s/x]T.E) ty 1 ' (T.E 1 ) A(x) = T 

1 5j (^(s),^) V ( T',E') 
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, . E(s) = false 

1 6> (when s T, E ) (when s T, E ) 

E(s) = true (T, E) (0, E') 

1 7) (when s PE) Jl 7 {(). E r ) 

E(s) = true (T, E) l| p (T 1 , E') T ± 0 

1 (when s T, E) ^ p (when s T', E') 

(T) (T,E)^ { Q.E>) 

19) (watch s T, E) ^ p (0,^) 

(T, E) r (r, E') V ± 0 
[ w) (watch s T, E) 1}, F (watch s T\ E') 

frr ^ m, e) r 1 (o, e,) (t 2 , e,) v, e') 

1 llJ {TuT 2 ,E) V lU ^ 2 {T',E') 

^ N (T 1} E) r (T 1 , E’) TVO 
1 12j (Ti,t 2 ,e) r (T'-T 2 ,E') 

It can be seen from this description of the operational semantics that when¬ 
ever (T, E) -l| p (T r , E') then the execution of T is either terminated, that is 
T' = 0, or suspended, that is T' is an expression where one has to execute a 
subexpression of the form (when s S), but E'(s ) = false (see the rule T 6 ). In 
other words, in our cooperative framework, the when instruction is the only 
one that may cause the interruption of the execution of a thread. 

The implementation of both the when and the watch instructions requires 
a stack. For instance, in (when si (when s 2 T)) the computation of T may 
progress only if both the signals .Si and s 2 are present. In 

(watch si (watch s 2 T 1 );T 2 );T 3 , 

we start executing T\. Assuming that at the end of the instant, the execution 
of T| is not completed, the computation in the following instant resumes with 
T 3 if si was present at the end of the instant, with T 2 if si was absent and s 2 
was present at the end of the instant, and with the residual of T\, otherwise. 
Note that whenever we spawn a new thread we start its execution with an 
empty stack of signals, as in the FairThreads model mu- 

A program P is a finite non-empty multi-set of threads. We denote with 
sig(T) (resp. sig(P)) the set of signals free in T (resp. in threads in P). To 
execute a program P in an environment E during one instant, we proceed 
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as follows: first schedule (non-deterministically) the atomic executions of 
the threads that compose it as long as some progress is possible and second 
transform all active (watch s T) instructions where the signal s is present 
into the terminated thread Q- To say that a thread T in an environment E 
is stuck we write (T, E)\. This is defined as 

(T,E)t i((T,E)f(T,E) (1) 


Notice that if (T, E)\ then T is either terminated or suspended in the context 
of E. To perform the abort operation associated with the watch construct at 
the end of the instant, we rely on the function [-Je defined as follows: 


[p\e = {\[t\ e \ t eP\} LOJs = 0 [T-r\ E =[T\ E] r 


[when s T\ E = 


(when s \T\e ) if E(s) = true 
(when s T) otherwise 


[watch s T\ e = 


0 if E(s ) = true 

(watch s \T\e) otherwise 


We then formalise as follows the execution during an instant of a program P 
in the environment E, where we rely on a multi-set notation. 


VTeP(T,E)t 
[ 1] (P,E) ([P\e,E) 


3 T eP -i(T, E) t (T, E) 4 P ' (T', E') 
(A) (P\{ \T\} U (IT'D U P', E 1 ) ^ (P", E") 
{P,E)MP",E") 


Finally, the input-output behaviour of a program is described by labelled 

transitions P P 1 where 1,0 C Int are the signals in the interface which 
are present at the beginning and at the end of the instant, respectively. As 
in Mealy machines, the transition means that from program (state) P with 
“input” signals / we move to program (state) P 1 with “output” signals O. 
This is formalised by the rule: 


(I/O) 

(P,E I>P )^{P',E l ) 

0 = {s G Int E'(s) = true} 


p 7 4° p' 


( true 

if s e / 

where: 

Eip(s ) = < false 

if s G (Int U sig(P )) — / 


y undefined otherwise 
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Note that we insist on having all free signals of the program in the domain 
of definition of the environment. 

To conclude this section we give some examples of derived constructions, 
which are frequently used in the programming practice. In what follows 
(local si • • ■ (local s n T) ■ ■ •) abbreviates as (local si, ... ,s n T), and a similar 
convention is used for when and watch. Moreover, we assume that the signals 
that are introduced in the following encodings (i.e. s in now, etc.) are fresh, 
that is they do not occur in the parameters (i.e. s ^ sig(T), etc.). 


(await s) 
(loop T ) 
(now T ) 
pause 
(exit s) 
(trap s T ) 


(when s 0) 

kl(s) where {s} = sig{T), kl(s) = T;A( s) 
(local s (emit s); (watch s T )) 

(local s (now (await s))) 

(emit s); pause 
(local s (watch s T)) 


and finally 

(present s T T') = (local t (thread (watch s pause; (thread T'; (emit £)))); 

(now (await s); (thread T; (emit i))); 

(await £)) 


The instruction (await s) suspends the computation till the signal s is present. 
The instruction (loop T) can be thought of as T; T; T; * • •. Note that in 
(loop T)\T', T' is dead code, i.e., it can never be executed. The instruc¬ 
tion (now T) runs T for the current instant, i.e., if the execution of T is 
not completed within the current instant then it is terminated. The instruc¬ 
tion pause suspends the execution of the thread for the current instant and 
resumes it in the following one. We may rely on this instruction to guar¬ 
antee the termination of the computation of each thread within an instant. 
The constructs trap/exit provide an elementary exception mechanism. The 
instruction (present s T T') branches on the presence of a signal. More pre¬ 
cisely, if s is emitted during the current instant, this construction spawns the 
thread T for execution, and blocks T' (which is thrown away at the next in¬ 
stant), while if s is not emitted, the thread T' is executed in the next instant, 
and T never gets performed. 


Remark 1 (comparison with |12j ) The model we have introduced is largely 
inspired by the original proposal d. The main novelties or variations are: 
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replacing parallel composition, the await and the loop instructions with, re¬ 
spectively, the thread and when constructs, and recursive definitions, and 
relying on a “big step” operational semantics. We also remark that in the 
definition of the conditional branching (present s T T') the expressions T 
and T' are under a thread instruction. This implies that their execution does 
not depend on when or watch signals that may be on top of them. If this 
must be the case, then we may prefix T and T' with suitable when and watch 
instructions. 


3 Implementations and applications 

Several implementations related to the model described in the previous sec¬ 
tion have been proposed over the years. Here, we briefly review some of them 
(in a more or less chronological order), highlighting their main features. 

Reactive-C |5J was proposed as a preprocessor of C for assembly-like reac¬ 
tive programming, and it has been used to implement SL. There also exists a 
reactive library very close to Reactive-C written in Standard ML [23]. Two 
sets of Java classes have been designed for reactive programming in Java: 
SugarCubes na and Junior d|. In these implementations, reactive threads 
are not mapped on Java threads and thus the problems raised by the latter 
(for example, the limitation on their number or their memory footprints) 
are avoided. Icobjs m is a framework for graphical reactive programming, 
built on top of SugarCubes. Icobjs have been used for video games, simu¬ 
lations in physics and simulations of the Ambient calculus. Both Java and 
ML have been extended with reactive primitives, respectively in Rejo [T] and 
ReactiveML ED FairThreads HQ £25| and Loft EDI define a thread-based 
framework in which reactive cooperative threads and preemptive threads can 
be used jointly. Finally, ULM urn proposes to use reactive programming, 
enriched with migration primitives, for global computing over the Web. This 
takes advantage of the fact that reactive programming, as opposed to the 
synchronous model of Esterel for instance, is well-suited for applications 
involving dynamic concurrency. 

Starting from the work initiated by Laurent Hazard on Junior, a lot of 
effort has been devoted to designing efficient implementations of reactive 
frameworks. Efficiency mainly comes from the absence of busy-waiting of 
suspended threads waiting for an event, and from scheduling techniques al¬ 
lowing direct access to the next thread to execute. As examples of efficiency- 
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critical applications recently implemented using the reactive style, we may 
mention the simulation of a complex network routing protocol for mobile 
ad-hoc networks described in ReactiveML [2T], the implementation of a Web 
server in Scheme |2Tr, and the implementation of cellular automata in mi, 
which we shall now describe in some details. 

Cellular automata (CA) are used in various simulation contexts, for exam¬ 
ple, physical simulations, fire propagation, or artificial life. These simulations 
basically consider large numbers of small-sized identical components, called 
cells, with local interactions and a global synchronized evolution. Concep¬ 
tually, the evolution of a CA is decomposed into couples of steps: during 
the first step, cells get information about the states of their neighbours and 
during the second step they change their own state according to the informa¬ 
tion obtained from the previous step. Usually, CA are coded as sequential 
programs, basically made of a single main loop which considers all cells in 
turn. Using the reactive style to program cellular automata, where each cell 
is a reactive thread, has the following advantages: 

• Instants naturally represent steps: at each instant, each cell changes its 
state according to the neighbours states at the previous instant, signals 
its new state, and then waits for the information about the state of its 
neighbours. 

• The behaviour of cells coded as look-up tables in usual CA implemen¬ 
tations is rather opaque. This is generally not felt as a big issue because 
cells behaviours are often very simple. However, in some contexts, for 
example artificial life, one may ask for more complex cell behaviours. 
In these cases, the modularity obtained with reactive programming is 
an advantage. 

• One can obtain efficient implementations of CA spaces in which each 
cell is implemented as a thread. To improve efficiency, cells can be 
created only when needed. Note that quiescent cells (with no active 
neighbour) are just waiting for an activation signal; their presence thus 
does not introduce any overhead at execution. 

Reactive programming focusses on behaviours rather than on data. En¬ 
tities found in video games can thus be naturally coded using reactive prim¬ 
itives. Similarly, we have also used the reactive model for interactive sim¬ 
ulation of physical systems. Indeed, the reactive style provides us with a 


very simple and modular way to describe the evolution of complex physical 
systems. The main features of this approach are simplicity of model construc¬ 
tion and high modularity of components. This approach allows us to express 
both continuous and discrete aspects of a model. For example, consider a 
planet/meteor system. A planet is implemented with a behaviour which, at 
each instant, emits a gravity signal with its coordinates. A meteor, at each 
instant, waits for the gravity signal and moves accordingly. One thus gets 
systems made of interacting components in which new components can be 
dynamically added. Applets illustrating this approach, coded in SugarCubes, 
are available on the Web j25j . 


4 Some issues 

In this section we briefly discuss some issues related to reactive programming. 

4.1 Values 

Practical programming languages that have been developed on top of the 
basic reactive model include data types beyond pure signals. For instance, 
we may have the inductive type of booleans bool — t | f, and the inductive 
type of natural numbers in unary notation nat — z | s of nat. At the very 
least, the reactive kernel embedded in a general purpose language should 
include ways of using the values manipulated in this language. There are 
two main approaches to adding values to the model: (1) to introduce refer¬ 
ences as in the ML language, and (2) to assume that signals carry values 
and that the last emission “covers” in a sense the previous ones (if any). 
In the latter case, an important design choice to make is to decide what 
is “the” value associated with a signal at a given instant, and what is the 
corresponding construct for consulting this value. The simplest model is to 
regard the value of a signal as ephemeral. That is, the value is updated, as 
for a reference, by the next emission of the given signal. However, this is 
not quite compatible with the idea that a signal is broadcast, and that all 
the running threads have a consistent view of it - either present or absent - 
at each instant. Therefore, some other mechanisms have been designed. In 
Esterel for instance, one assumes for each type of signal value a function 
for combining the various values emitted on that signal, and the actual value 
carried by the signal at some instant is the combination of all the values 
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emitted during this instant (in ESTEREL, with the strong synchrony hypoth¬ 
esis, the combination function should be associative and commutative, since 
the result should be independent of any scheduling). A similar approach has 
been followed in SugarCubes ra and ReactiveML [2Tj. Notice that in the 
reactive model, where one cannot statically predict that a signal will or will 
not be emitted, one has to collect the value of a signal only at the beginning 
of the next instant. One may also trigger a processing mechanism each time 
a value is emitted on a signal. Another possibility that is considered in some 
implementations is to specify, in a receive statement, the rank of the value 
(in the emission order) in which one is interested. 

4.2 Reactivity 

A first property that we would like to ensure regarding reactive programs is 
that they should indeed be reactive, in the following (coinductive) sense: 

Definition 2 A program P is reactive if for every choice I of the input 
signals there are O, P' such that P ^ P' and P' is reactive. 

The reactivity property is not for free. For instance, the thread A = (await s); A 
may potentially loop within an instant. Whenever a thread loops within an 
instant the computation of the whole program is blocked as the instant never 
terminates. One approach to ensure reactivity is to produce a static analysis 
that guarantees that all loops that may occur within an instant traverse a 
pause instruction. 

While reactivity is a necessary property, it does not guarantee that in 
practice the program will react for arbitrarily many instants and that this 
will happen within reasonable time and/or space. A first problem has to do 
with the implementation of the when and watch instructions. Consider, the 
thread A = (local s (watch s pause; A)). Every time the execution crosses 
the watch instruction it causes the insertion of a new signal s which may 
potentially abort the execution (although this is not the case with this par¬ 
ticular program). Thus the execution of this program may potentially cause 
a stack overflow. This kind of pathological programs can be removed by a 
static analysis that checks that there is no loop in the program (possibly 
going through several instants) that may cause an increase of the stack. 

A second problem is due to the fact that the number of (active) threads 
and signals may grow without limit. Indeed, it can be shown that our basic 
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language is Turing complete. In practice, we need to control the number of 
threads, and in this respect an interesting feature of the language is the watch 
instruction which allows to terminate explicitly the execution of a thread (at 
the end of an instant). 

Finally, a third problem, as regards reactivity, is caused by the introduc¬ 
tion of data values. The size of the values we are interested in, like lists or 
trees, is usually not a priori bounded. What does it mean to ensure reactivity 
in this case? We have in nan considered three increasingly ambitious goals 
in this respect. A first one is to ensure that every instant terminates. A sec¬ 
ond one is to guarantee that the computation of an instant terminates within 
feasible bounds which depend on the size of the parameters of the program at 
the beginning of the instant. A third one is to guarantee that the parameters 
of the program stay within certain bounds, and thus the resources needed 
for the execution of the system are controlled for arbitrarily many instants. 
In particular, we have been adapting and extending techniques developed in 
the framework of (first-order) functional languages. The general idea is that 
polynomial time or space bounds can be obtained by combining traditional 
termination techniques for term rewriting systems with an analysis of the size 
of computed values based on the notion of quasi-interpretation (jliEj)- Thus, 
in a nutshell, ensuring “feasible reactivity” requires a suitable termination 
proof and bounds on data size. 

4.3 Determinism 

We say that two programs P, P' are equal up to renaming if there is a bijection 
from sig(P) to sig(P') that is the identity on the observable signal names 
in the interface Int and that when applied to P produces P' . As usual, an 
inspection of the semantics shows that the observable behaviour of a program 
does not depend on the specific choice of its internal signal names. First we 
define deterministic programs. As with the notion of reactivity, determinism 
should hold at every instant, and therefore our definition is coinductive. 

Definition 3 A program P is deterministic if for every choice I of the input 

signals if P I ^> 1 Pi and P 1 ^~ P 2 then 0\ = O 2 and P\ = P 2 up to the same 
renaming, and P\ is deterministic. 

It is immediate to verify that the evaluation of a thread T in an environment 
E is deterministic. Therefore the only potential source of non-determinism 
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comes from the scheduling of the threads. The basic remark is that the 
emission of a signal can never block the execution of a statement within an 
instant. The more we add signals the more the computation of a thread can 
progress within an instant. Of course, this property relies on the fact that 
we cannot detect the absence of a signal before the end of the instant. 

Proposition 4 All programs are deterministic. 

Clearly, this property is likely to be lost when adding values to the model. 
Assuming that we have valued signals, consider for instance the program 
P = {|(emit s t), (emit s f)|} where two threads emit the boolean values t and 
f, respectively, on the signal s. The value which is observed on the signal 
at the end of the instant depends on the scheduling of the threads (unless 
the values are combined using an associative and commutative function, as 
in Esterel). So it seems that we have to accept the idea that when intro¬ 
ducing data types the result of the program depends on the scheduler. In 
practice, one may assume that the scheduler is deterministic in the program 
and the input. This is a significant difference with preemptive concurrency. 
In preemptive concurrency, the scheduling policy may depend on factors such 
as the current workload which are independent from the program and the in¬ 
put. Assuming a deterministic scheduler has a positive effect on the process 
of testing, tracing, and debugging concurrent programs. Besides determin¬ 
ism, it might be reasonable to put additional constraints on the scheduler. 
One such constraint is the following: if a thread suspends its execution dur¬ 
ing an instant then all the threads that are ready to run at the moment of 
the suspension will be given a chance to progress before the computation of 
the suspended thread is resumed (if ever). With such a scheduler in mind, it 
makes sense to define: 

yield = (local s (thread (emit s)); (await s)) 

4.4 Program equivalence 

We have described the operational semantics of reactive and deterministic 
programs as a reaction to a given input, producing a unique output and 
continuation. Looking for a more abstract, extensional semantics, one possi¬ 
bility is to consider that it is determined by the set tr(P) of infinite traces 
associated with the possible runs of the program P. Namely: 

tr{P ) = {(JiMXVOa) • • • | P 11 ^ 1 Pi ^ P 2 • • • } 
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Another possibility could be to define a notion of bisimulation. Namely, 
consider the largest (symmetric) relation R on programs that satisfies the 

following condition: for every (P, P') G R and input I, if P P\ then P' 

P[ and (Pi, P[) G P. It is important to notice that for our deterministic 
language these two notions coincide. 

Proposition 5 Two reactive and deterministic programs are trace equivalent 
iff they are bisimilar. 

Of course, this reduces considerably the debate on what the right notion of 
program equivalence is. The notion of weak bisimulation - another familiar 
concept in the semantics of concurrency - is also missing. However, we 
must point out that, although the problem of defining program equivalence 
has an obvious solution, little work has been done so far on the problem of 
defining and characterising a suitable notion of thread equivalence which is 
preserved by program contexts. Moreover, as we have seen, adding values to 
the language turns it into a non-detcrministic model, for which no notion of 
equivalence has been investigated so far. 
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